Generic bootstrapping architecture (GBA) enables the authentication of users for a particular service. GBA uses several different elements including user equipment (UE), an application server or network application function (NAF) that provides a particular service, a bootstrapping server function (BSF) and a mobile operator's home subscriber server (HSS) or home location register (HLR). These elements are shown in the system 10 of FIG. 1. GBA is a well-established standard that employs a defined interface (Ub) between the UE and a network-based BSF. The interface flows involving Ub are shown circled in FIG. 1.
However, this Ub flow presents a number of difficulties. Firstly, there are several messages backwards and forwards (four in the successful case and even more in an unsuccessful or error case) and it is desirable to reduce the number of messages. Secondly, this procedure requires an application protocol connection (specifically HTTP) from a mobile device terminated at the BSF. The BSF is a sensitive network node (it stores authentication vectors (AVs) and is able to retrieve additional AVs at will from a network operator's HLR or HSS). This raises the risk for rogue (or just uncontrolled) devices on the mobile network sending malformed HTTP requests towards the BSF to either crash it or exploit vulnerabilities in the HTTP server implementation, which may compromise the BSF. There is also a problem that the end device might not support an HTTP client. If an alternative protocol like CoAP (constrained application protocol) is used (which is unacknowledged) then there are potentially even more messages required to recover from lost or missing messages in the flow.
Thirdly, the Ub interface requires the device to present an identifier to start the protocol. This may be either an “IMPI” based on the IMSI or a disguised identifier called a “TMPI” (rather like a TMSI), which is used since exposure of the same IMPI repeatedly allows tracking. The mechanism for generating TMPIs and storing the mapping between TMPI and IMPI at the BSF is rather complex, and adds to BSF cost and complexity.
GBA Push is an alternative part of the 3GPP standards and essentially removes the Ub interface, replacing it by with a “pushed” message (GBA Push Information, GPI) over an interface called the Upa. While this simplifies the message flows, it comes with a number of its own problems and limitations, including:
a) The BSF never really authenticates the device. It just sends out some key material to a network application function (NAF) with an assurance that if anything else can recover the same key material, then it must be the relevant device. In other words, this provides a kind of indirect authentication but this is not as useful as direct authentication.
b) Various error cases involving lost messages (e.g. GPI message never arrives at UE), corrupted messages (e.g. arrives but with incorrect bits), and synchronisation problems (e.g. a USIM having an authentication counter different from the counter at the HLR/HSS) cannot easily be detected or corrected. Therefore, the NAF may perform multiple attempts or keep requesting further GPI messages from the BSF.
c) There is no bootstrapping transaction identifier (B-TID)—a transaction identifier used to preserve anonymity). Instead, a P-TID may be chosen by the NAF and the NAF must further be advised in advance of the device's real identity. This is not preferable for privacy reasons. Furthermore, if the device presents a fake identity, then the NAF may send out the GPI in vain (the Ks_NAF will never be successfully received and recovered and the NAF may be left hanging with a broken security association).
d) The model is “one push message per NAF”. It is not possible to use a single push message to set up a shared key that can be used with multiple NAFs. This is a particular limitation for device management, where a Ks and associated Ks_NAF is likely to have been set up already to secure the device management (DM) protocol. It is then desirable that additional Ks_NAF (for further application and service keys) are derived immediately, rather than forcing a re-run of GBA-Push.
Therefore, there is required a system and method that overcomes these problems.